Orpjovkf aelkr
ou can observe many talented people who stand as counter examples: Shaun Inman, Quora User, and Justin Ouellette are some of my favorites. More problematically, this argument is the result of numerous bad ideas about learning, definition, and process. Being a long-time generalist designer myself, I feel passionately that this myth is holding back our field and deserves to be debunked. 'Learning isn't a zero-sum activity.' These skills are not mutually exclusive. Picking up Python won't make you forget how to kern. We all have many years ahead of us in our careers, and they can be used to learn anything. The central counter-argument here is that any learning comes with opportunity cost. Learning Python might very well take up time that you would otherwise use for studying, say, product management. This is true, in theory. But in practice, most designers I know, including myself prior to joining Quora, are not learning at their maximum rate. I have spent much of my career solving the same design problems over and over again with no substantive personal growth to show for it. I don't think my situation is unique. But even if you were learning at your maximum rate, the opportunity cost argument actually works in favor of the multi-disciplinary approach. Design and its component practices are like any other craft: you can always develop a deeper familiarity with the minutiae, asymptotically approaching mastery. But this is a process with diminishing returns. Would you rather carve a door 1% better than you did last year, or learn how to build the rest of the house in the same amount of time? As I argue below, the connective tissue between these skills may actually be more valuable than incremental gains in a single practice. And keep in mind, this is more an issue of prioritization — what do you want to learn right now — than one of long-term skill development. You have the rest of your life to carve a better door. 'Design is already not a single skill.' The notion that you can't be good at more than one practice is silly because most practices are themselves comprised of more granular skill sets. Typography teaches you about kerning, font pairing, and legibility. But typography itself is just one component of what we call graphic design, which is the unified application of many additional skills like color theory, layout design, and so on. We may call them different things, but that's an abstraction to aid study and discussion. Their utility, and our primary concern, is in their function as part of a holistic'' system, where they work together to achieve an outcome. This never stops being true, no matter how far up the chain you go. 'A unified process fosters better work. If you accept the holistic view, then you have to accept that design itself is just a piece of a larger effort, which is to build something that changes the world. Design work that never gets built is not real; you cannot truly separate design from implementation. The product development process, then, must be built to ensure this holistic perspective is not lost. The best implementation reflects the designer's intent, and the best design reflects the product's goals. There's a through-line that binds every step: the product needs to reflect a single vision, a consistent explanation (about human behavior, about the technology) for why it will succeed. The preservation of that through-line can be more important than any individual step, as a mis-aligned product competes with itself before it competes with the market. I think this dynamic is why single developer products (think: Instapaper,Pinboard, etc.) can often be so successful despite their inherent constraints: fewer chances for misalignment. It's just easier to align a small team than a large one, especially when the designer shares the same technical language as the engineer from working in the same codebase. It's also easier for one person to harmonize aspects of a product when they can accurately reason about trade-offs between the various moving parts of the system. The other implication of this perspective is the admission that this process is''not'' inherently linear. Taken as an interwoven system, design and implementation can and should push on each other in equal measure. Implementation often reveals gaps in the design: undocumented states and conditions, bad assumptions about usage, and other realities hard to predict when locked in Photoshop. The designer who implements their own work experiences these feedback loops directly, and can incorporate the appropriate changes in their final context. '''You don't have to be great at everything to create great work. The aim of developing your skills is not actually to have more skill ''per-se. We learn in order to make, and its the quality of our output that is the ultimate measure of our efforts. These concepts are tightly related, but there are systems for producing stronger work independent of skill. When people hear "designers should learn to code" they often take it to mean that designers should be as talented an engineer as someone who does it full-time. Thanks to technical advances, this is decreasingly the case. Here at Quora, we have a sophisticated infrastructure that empowers designers to build complex features with a rudimentary knowledge of programming (relative to an engineer). I wrote about this more extensively in my post, [http://irondavy.quora.com/Designers-Will-Code ''Designers Will Code]. This is not unique to our culture here, GitHub's Quora User has alsotalked about this phenomenon. This is currently overlooked because these systems haven't become common-place, but that's a chicken-and-egg process: investment in creating these tools is justified only if you actually have a generalist team. Another example: one problem with discussing this topic in a theoretical light is that designers don't actually work in a vacuum of their individual skill. As a member of a larger organization, your individual variation in skill is less important than the aggregate expertise of the team. I'm not the strongest programmer on our design team, but my peers can help me make informed decisions. Everyone on our team draws on the skills of everyone else, and the final work will be stronger than any individual would've been capable of. This may sound like specialization but it's fundamentally different. The expectation is that every individual is growing towards independence, not developing dependencies. This is not abstract: by becoming a better programmer I have concretely absorbed the tasks that what would typically define a discrete role (front-end engineer) at most other companies. ---- It's curious that designers are so eager to place limitations on their potential, but I've experienced those feelings first hand. Prior to joining Quora, I did not have a good reason to believe I could ever be a productive programmer. All of my attempts to learn in evenings and weekends were not particularly fruitful. But when placed in an environment where I'm both expected and empowered to develop these skills, I have indeed been able to. Perhaps it's not for everyone, but I'm positive that the number of designers who would thrive in a generalist — a.k.a. multi-disciplinary a.k.a. holistic — design role is far greater than the number of designers who are actually encouraged to try. To my fellow jacks-of-all-trades: don't give up.